Wir beginnen mit der Reconnaissance, um Informationen über das Zielsystem zu sammeln. Dies umfasst das Scannen des Netzwerks und das Auflisten von Hosts, um potenzielle Angriffspunkte zu identifizieren.
ARP-Scan zeigt uns die MAC-Adresse und den Hersteller der Netzwerkkarte des Ziels. Dies kann hilfreich sein, um das Betriebssystem oder die verwendete Virtualisierungstechnologie zu bestimmen.
Der Eintrag in der /etc/hosts-Datei ermöglicht uns, das Zielsystem über den Hostnamen `djinn2.vln` anzusprechen. Dies erleichtert die weitere Analyse und das Testen.
Nmap identifiziert offene Ports und Dienste auf dem Zielsystem. Besonders interessant sind: - FTP (Port 21): Anonymer Zugriff ist erlaubt, was möglicherweise sensible Daten offenlegt. - SSH (Port 22): Ermöglicht die sichere Fernanmeldung. - Port 1337: Ein benutzerdefinierter Dienst (waste?) mit einer interessanten Begrüßungsnachricht. - HTTP (Ports 5000 und 7331): Webserver, die möglicherweise anfällige Anwendungen hosten. Die Werkzeug-Versionen (Python 3.6.9) deuten auf veraltete Software hin, die bekannte Schwachstellen aufweisen könnte.
Nachdem wir die offenen Ports identifiziert haben, konzentrieren wir uns auf die Webserver, um weitere Informationen zu sammeln und potenzielle Schwachstellen zu finden.
Nikto findet verschiedene potenzielle Sicherheitsprobleme: - Fehlende X-Frame-Options und X-Content-Type-Options Header: Erhöhen das Risiko von Clickjacking- und MIME-Sniffing-Angriffen. - Veraltete Python-Version: Kann bekannte Schwachstellen enthalten. - Interessante Datei `/robots.txt`: Sollte weiter untersucht werden. - Unerwartete HTTP-Methode `PTINS`: Könnte auf eine benutzerdefinierte oder fehlerhafte Implementierung hindeuten. - Fund einer Datei `#wp-config.php#`: Dies ist höchstwahrscheinlich eine Backup-Datei, die sensible Informationen wie Datenbank-Zugangsdaten enthalten könnte.
Nikto findet auf Port 5000 ähnliche Probleme wie auf Port 7331: - Fehlende Header und veraltete Python-Version. - Auch hier die unerwartete HTTP-Methode `PTINS`, zusätzlich zu `PST`.
Gobuster findet die Datei `/robots.txt` und das Verzeichnis `/source` auf Port 7331. `/source` könnte Quellcode der Anwendung enthalten, was bei der Suche nach Schwachstellen sehr hilfreich sein kann.
Die `/robots.txt` Datei verweist auf das Verzeichnis `/letshack`. Dies ist ein weiterer interessanter Pfad, den wir untersuchen sollten.
Nach der Enumeration der Webserver untersuchen wir den FTP-Server und versuchen, uns Zugriff auf das System zu verschaffen.
Wir verbinden uns anonym mit dem FTP-Server und listen die Dateien auf. Die Datei `creds.txt` könnte Zugangsdaten enthalten. Der Versuch, eine Reverse-Shell hochzuladen (`revshell.war`) scheitert aufgrund fehlender Berechtigungen. Auch der Versuch, das Verzeichnis zu wechseln, schlägt fehl.
Da wir keine Dateien hochladen können, laden wir die vorhandenen Dateien mit `wget` herunter, um sie lokal zu analysieren.
Wir überprüfen, ob die Dateien erfolgreich heruntergeladen wurden.
Die Datei `creds.txt` enthält möglicherweise Zugangsdaten für einen Benutzer. Wir notieren uns den Benutzernamen und das (gehashte) Passwort.
Die Datei `game.txt` enthält Hinweise auf Benutzer und möglicherweise eine "sichere" Authentifizierungsmethode.
Die Datei `message.txt` bestätigt die Existenz der Benutzer `nitish81299` und `Ugtan_`.
Wir verbinden uns mit dem Dienst auf Port 1337. Es scheint ein Spiel zu sein.
Wir haben festgestellt, dass der Webserver auf Port 5000 anfällig für Server-Side Template Injection (SSTI) sein könnte. Um dies zu bestätigen, führen wir einen Proof of Concept (POC) durch.
Wir versuchen, eine einfache SSTI-Payload im "Math game" zu injizieren. Der Server scheint dies jedoch zu erkennen und blockiert den Versuch.
Wir versuchen eine komplexere Payload, um die `/etc/passwd` Datei auszulesen. Auch dieser Versuch wird blockiert.
Obwohl die Versuche im "Math game" fehlschlagen, deutet die Reaktion des Servers darauf hin, dass SSTI tatsächlich vorhanden sein könnte. Wir versuchen nun, die SSTI-Schwachstelle auf Port 5000 auszunutzen.
Wir senden eine POST-Anfrage an Port 5000 mit dem Parameter `username`, der den Befehl `id` enthält. Die Ausgabe zeigt, dass der Befehl erfolgreich ausgeführt wurde und wir als Benutzer `www-data` agieren.
Wir verwenden die HTTP-Methode `PST` (die Nikto zuvor als ungewöhnlich identifiziert hat) und senden den Befehl `ls`. Die Ausgabe zeigt, dass die Datei `app.py` vorhanden ist.
Wir listen den Inhalt des `/home`-Verzeichnisses auf und finden die Benutzer `nitish` und `ugtan`.
Wir lesen die `/etc/passwd`-Datei und filtern die Benutzer heraus, die eine Bash-Shell verwenden. Dies bestätigt die Existenz der Benutzer `root`, `nitish` und `ugtan`.
Diese Befehle zeigen eindeutig, dass wir beliebige Befehle auf dem System ausführen können, was die Existenz einer SSTI-Schwachstelle bestätigt.
Nachdem wir initialen Zugriff auf das System als `www-data` erhalten haben, versuchen wir, unsere Privilegien zu erhöhen, um Root-Zugriff zu erlangen.
Wir erstellen eine Reverse-TCP-Payload mit `msfvenom`, um eine Meterpreter-Session zu erhalten.
Wir starten `msfconsole` und konfigurieren einen Handler, um die Reverse-Shell zu empfangen.
Wir laden die Payload `eins.elf` über die SSTI-Schwachstelle auf das Zielsystem in das `/tmp`-Verzeichnis herunter.
Wir überprüfen, ob die Payload erfolgreich heruntergeladen wurde.
Wir ändern die Berechtigungen der Payload, um sie ausführbar zu machen.
Wir überprüfen, ob die Berechtigungen erfolgreich geändert wurden.
Wir führen die Payload aus und erhalten eine Meterpreter-Session als `www-data`.
Nachdem wir eine Meterpreter-Session als `www-data` erhalten haben, suchen wir nach Möglichkeiten, unsere Privilegien zu erhöhen.
Wir überprüfen, dass wir als `www-data` angemeldet sind.
Wir versuchen, den `search suggester` zu verwenden, um nach Exploits zu suchen, die zur Privilegienerhöhung geeignet sind.
Wir verwenden den `local_exploit_suggester`, um potenzielle lokale Exploits zu identifizieren.
Der `local_exploit_suggester` identifiziert mehrere potenzielle Exploits, darunter `cve_2021_4034_pwnkit_lpe_pkexec` (PwnKit).
Wir verwenden den PwnKit-Exploit, um Root-Privilegien zu erlangen.
**Fantastisch! Der Root-Zugriff war erfolgreich! Nun haben wir unser Ziel erreicht!** Wir überprüfen, dass wir jetzt als `root` angemeldet sind.
Der folgende Befehl zeigt, dass Root-Privilegienerlangung über den PwnKit Exploit erfolgt ist.
Der Befehl id zeigt, dass die aktuelle UID 0 ist, was bedeutet, dass der Benutzer Root-Rechte hat.
Das Skript proof.sh bestätigt den erfolgreichen Root-Zugriff.